T2b Code Review — PR #446

Verdict: APPROVE

Reviewed all 3 changed files (constants.ts, zap.ts, TradingWidget.tsx). Here are my findings:

1. ZAP_PLOTLINK address update

0x04f557F8D2806B34FC832a534c08DF514D4dfEeF — correctly updated on mainnet only; testnet remains zeroed out. Checksum format looks valid. OK.

2. Gas limit 3M → 5M

Reasonable. PR description states HUNT MCV2 double-mint needs ~3.05M, so 3M was barely insufficient. 5M provides ~65% headroom which is standard practice for multi-hop DeFi transactions. The gas param is a limit (unused gas is refunded), so the only downside is a slightly higher upfront ETH reservation — negligible for users. OK.

3. Balance display below PAY WITH selector

Moved correctly. The balance and insufficient-balance warning now render inside the tab === "buy" && isZapAvailable block, directly under the token buttons. For sell tab and non-zap buy, the original position (below the input) is preserved via (tab === "sell" || !isZapAvailable) guards. Logic is clean. OK.

4. MAX button (buy tab)

• ETH: ethBal - ETH_GAS_BUFFER (0.001 ETH) — good, prevents users from draining their entire balance and failing on gas. The constant is correctly defined as BigInt("1000000000000000") (10^15 wei = 0.001 ETH). Floor at zero handled.
• USDC/HUNT: reads balanceOf from erc20BalanceToken — correct, uses full balance.
• PLOT: reads balanceOf from PLOT_TOKEN — correct.
• All paths call getZapQuote with "exact-input" to convert the pay-token balance into story tokens, then set the amount field. This is the right direction (user sees output tokens).
• Edge case: maxBalance <= 0 returns early — good.
• Error handling: silent catch — acceptable for a convenience button; user can still type manually.
• One minor note: The USDC/HUNT path does a fresh readContract for balance instead of using the already-fetched balance state variable. This means a redundant RPC call but ensures the value is current. Acceptable trade-off.

OK.

5. Label "TOKENS TO BUY" → "STORY TOKENS TO BUY"

Only on buy tab; sell tab remains "Tokens to sell". OK.

6. "Trade" → "Trade to Support" + tooltip

Tooltip uses CSS-only hover (group-hover:block) — no JS state needed, clean approach. Tooltip text accurately describes the 5% creator royalty. pointer-events-none prevents tooltip from stealing hover. z-10 ensures it renders above other elements. OK.

7. Insufficient balance warning

For buy tab with zap: rendered below the PAY WITH selector.
For sell tab / non-zap buy: rendered below the input field.
Guards (tab === "sell" || !isZapAvailable) are consistent between balance display and warning. OK.

8. Security check

• No hardcoded private keys or secrets.
• Contract address is a deploy-time constant — appropriate.
• Gas buffer is a sensible constant, not a magic number in-line.
• Arrow comment change (→ to ->) is cosmetic only, no logic change.
• publicClient.readContract calls use typed ABIs — safe.

9. Code quality

• useCallback dependency arrays look complete and correct.
• pr-14 class applied to both buy and sell tabs now (for MAX button spacing) — correct.
• No unused imports or dead code introduced.
• Single commit, well-structured message.

No issues found. Approved.

T2b Review: PR #446 — Trading widget bug fix + UX

APPROVED ✅

Bug fixes:

• ZAP_PLOTLINK address updated to 0x04f557F8D2806B34FC832a534c08DF514D4dfEeF
• Gas limit 3M → 5M reasonable (HUNT needs ~3.05M, unused gas refunded)

UX changes — all verified:

• Balance moved below PAY WITH selector
• MAX button: ETH with 0.001 gas buffer, USDC/HUNT full balance, all use getZapQuote
• Label: "Story tokens to buy" ✅
• "Trade to Support" + tooltip with 5% royalty description ✅
• Insufficient balance warnings work for all 4 tokens

No security issues, clean implementation.

Verdict: APPROVE

Summary

The widget fixes are coherent, the root-cause contract address update is in place, and the PR is now green. I don't see any remaining correctness or UX blockers.

Findings

• [resolved] Remaining CI gate is green.
  • File: src/components/TradingWidget.tsx:151
  • Suggestion: None.

Decision

Approving because the bug fixes and UX updates are correct and the PR passes checks.